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FOREWORD 


The  Systems  Research  Laboratory  of  the  U.S.  Army  Research 
Institute  for  the  Behavioral  and  Social  Sciences  (ARI)  supports 
the  Army  with  research  and  development  on  manpower,  personnel, 
training,  and  human  performance  issues  as  they  impact  the  devel¬ 
opment,  acquisition,  and  operational  performance  of  Army  systems 
and  the  combat  readiness  and  effectiveness  of  Army  units.  Any 
consideration  of  the  combat  readiness  and  effectiveness  of  Army 
units  must  take  into  account  how  the  personnel  and  equipment  in 
the  unit  are  organized  to  conduct  and  support  the  combat  opera¬ 
tions.  Consequently,  there  is  a  need  to  develop  tools  to  in¬ 
crease  the  effectiveness,  efficiency,  and  reliability  of  the 
process  of  designing  units.  The  Fort  Bliss  Field  Unit  is 
conducting  Advanced  Development  (6.3A)  research  to  meet  this 
need. 


This  research  product  is  an  introduction  to  a  computer 
software  package.  Systematic  Organizational  Design  (SORD) ,  which 
standardizes  the  process  and  structure  for  creating  and  document¬ 
ing  initial  concepts  for  a  unit's  organizational  design.  SORD 
aids  in  the  development  of  a  document  called  a  unit  reference 
sheet  (URS)  that  has  sufficient  detail  in  personnel  and  equipment 
requirements  and  capabilities  to  permit  its  use  in  Army  studies 
and  cost  analyses.  The  software  also  assures  a  high  degree  of 
uniformity,  producing  a  URS  that  is  an  acceptable  reference  for 
organization  documentors. 

SORD  was  developed  with  the  encouragement  of  the  Deputy 
Chief  of  Staff  for  Personnel  at  Headquarters,  Department  of  the 
Army.  The  Current  Forces  Directorate  at  the  Combined  Arms  Combat 
Development  Activity  of  the  U.S.  Army  Training  and  Doctrine  Com¬ 
mand  (TRADOC)  was  the  principal  proponent  of  the  research  and 
development  effort  from  its  inception,  with  continuing  interest 
from  the  Organization  Directorate  of  the  Deputy  Chief  of  Staff 
for  Combat  Development  (DCSCD)  of  Headquarters  TRADOC. 

The  SORD  process  discussed  in  this  primer  was  briefed  to 
two  successive  TRADOC  DCSCDs.  Prototypes  of  SORD  were  demonstra¬ 
ted  at  the  XXVIII  Army  Operations  Research  Symposium  and  the  23rd 
Meeting  of  the  Department  of  Defense  Human  Factors  Engineering 
Technical  Group.  Version  2.0  of  the  software,  scheduled  for 
release  during  the  second  quarter  of  fiscal  year  1991,  will 
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SYSTEMATIC  ORGANIZATIONAL  DESIGN  (SORD)  METHODOLOGY: 

A  PRIMER 


Introduction 


Origin  and  Status  of  SORD 

The  U.S.  Army  Research  Institute  (ARI)  unit  design  project 
began  under  GEN  Thurman  when  he  was  the  Headquarters,  Department 
of  Army  (HQ  DA)  Deputy  Chief  of  Staff  for  Personnel  (DCSPER) ,  and 
received  continuing  support  under  his  successor,  LTG  Elton.  Both 
DCSPERs  encouraged  ARI  to  address  the  Army's  need  for 
standardized  and  objective  methods  for  organizing  soldiers  and 
their  equipment  into  cost  and  operationally  effective  units.  The 
SORD  methodology  was  designated  one  of  the  highest  priority  ARI 
research  tasks  by  the  U.S.  Army  Training  and  Doctrine  Command 
(TRADOC)  during  the  final  two  years  of  its  development.  SORD 
will  soon  become  the  required,  standard  technique  for  designing 
Army  units,  as  specified  in  a  draft  revision  to  TRADOC  Regulation 
71-17. 


The  Force  Design  Context  and  Process 

Our  initial  review  of  Army  and  TRADOC  regulations  that 
address  the  force  design  process  and  our  interviews  with  force 
designers  at  selected  TRADOC  facilities  showed  that  force  design 
is  a  major  factor  in  the  Concept  Based  Requirements  System 
(CBRS) ,  and  is  one  of  the  first  activities  completed  in  the  CBRS 
(see  TRADOC  Regulation  11-15) .  The  processes  and  activities 
TRADOC  employs  to  determine  "How  the  Army  will  fight,"  require 
the  early  formulation  of  ideas,  evolving  into  more  detailed 
concepts,  on  how  to  organize  units  to  conduct  and  support  that 
fight.  These  initial  concepts  for  organizing  units  are 
incorporated  into  a  supporting  document  called  the  Unit  Reference 
Sheet  (URS) .  The  URS  supports  and  is  a  basis  for  later 
conceptual  and  doctrinal  studies  and  analyses,  and  depicts,  in 
summary  form,  the  Table  of  Organization  and  Equipment  (TOE)  unit 
expected  to  result  from  approval  of  the  study  or  concept  (see 
TRADOC  Regulation  71-17) . 

Once  the  organizational  concepts  contained  in  the  URS  are 
approved,  there  are  numerous  prescribed  and  often  automated 
planning  documents  that  will  refine  the  URS  and  give  shape,  size, 
and  detail  to  the  organization  created.  For  example,  all  of  the 
following  documentation  builds  on  the  URS:  the  Automated  Unit 
Reference  Sheet  (AURS) ,  the  Draft  TOE  ( DTOE ) ,  Basis  of  Issue  Plan 
(BOIP) ,  the  Qualitative  and  Quantitative  Personnel  Requirements 
Information  (QQPRI) ,  and  the  results  of  Manpower  Requirements 
Criteria  (MARC)  studies  (see  Army  Regulations  71-2  and  570-2,  and 
TRADOC  Regulations  71-15  and  71-17). 
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Yet,  by  the  very  nature  of  processes  that  govern  the 
development  of  concepts,  the  URS  development  process  must  be  a 
creative  act  oriented  toward  the  future,  and  relatively 
unconstrained  by  regulations  and  doctrine  that  prescribe  how  to 
organize  and  use  '’available”  resources.  The  URS  development 
process  must  portray  an  objectively  derived  design  for  "future" 
battles  that  may  employ  resources  and  doctrine  that  do  not  now 
exist. 


The  process  that  currently  exists  to  develop  a  URS  is 
designed  to  facilitate  a  search  for  innovative  solutions  to  unit 
design  issues.  After  HQ  TRADOC  initiates  a  major  combined  arms 
force  structure  study,  the  Current  Forces  Directorate  (CFD)  at 
the  Combined  Arms  Combat  Development  Activity  (CACDA) ,  Fort 
Leavenworth,  acts  as  the  study  agency.  CFD-CACDA  convenes  a 
series  of  action  officer  workshops  for  the  combat  developers 
responsible  for  the  functional  areas  incorporated  into  the 
mission  of  the  unit  to  be  designed  or  redesigned.  With  guidance 
provided  by  CFD-CACDA  and  the  subject  matter  experts  from  the 
responsible  TRADOC  schools  and  centers,  new  design  concepts  are 
repeatedly  revised  and  finally  integrated  into  one  URS.  Then, 
the  URS  undergoes  a  lengthy  review  and  revision  process  until  it 
gets  approval  by  HQ  DA. 

While  "The  Process"  works,  it  is  hindered  by  the  absence  of 
an  explicit  methodology,  i.e,  tools  or  aids  that  could  facilitate 
the  process.  Consequently,  it  is  much  less  efficient  than  it 
could  be.  Incorporated  in  the  process  are  the  experiences  and 
traditions  of  the  combat  developers  who  participate  in  the 
process.  In  other  words,  the  process  by  which  these  designs  are 
conceived  is  peculiar  to  each  combat  developer.  As  a  result, 
repetitive  communications  among  decision  nodes  are  required 
before  various  portions  of  the  design  can  be  integrated  into  one 
URS.  The  process  is  similarly  hindered  as  the  URS  moves  through 
the  review  and  approval  chain.  This  lack  of  efficiency  in  the 
URS  development  process  is  further  confounded  by  the  fact  that 
the  time  available  for  the  process  is  generally  quite  limited. 
Furthermore,  there  is  no  procedure  or  requirement  for  maintaining 
an  audit  trail.  Consequently,  independently  convened  URS 
development  teams  could  each  create  perfectly  valid  designs  that 
differ  in  substantial  ways  from  each  other,  without  anyone  being 
able  to  determine  what  differences  there  may  have  been  in  the 
design  rationale  that  caused  the  designs  to  be  different. 

Army  Need 

The  need  therefore  exists  to  standardize  the  current  process 
and  make  it  work  more  effectively,  efficiently,  and  reliably. 

(1)  A  standardized  process  will  drive  and  control  the 
development  of  a  URS.  Once  the  process  is  in  the  hands  of  the 
study  agency  at  the  CACDA  integrating  center,  the  study  manager 
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will  be  in  a  position  to  be  proactive  rather  than  reactive  in  the 
guidance  given  to  subordinate  schools  and  centers. 


(2)  The  rapid  pace  of  changes  in  mission  requirements,  high 
technology,  and  equipment  and  personnel  assets  has  produced  a 
high  workload  for  force  designers.  Over  the  past  several  years, 
TRADOC  has  had  to  design  or  redesign  over  300  TOE  units  per  year 
and  for  each  unit  up  to  three  URSs  have  been  created.  There  is 
good  reason  to  believe  that  the  numbers  of  unit  design  programs 
will  grow  rather  than  shrink,  and  that  the  number  of  authorized 
designers  will  shrink  rather  than  grow. 

(3)  There  is  a  movement  to  centralize  the  TOE  documentation 
process.  Now,  the  same  combat  developers  who  create  the  URS 
subsequently  document  the  TOE.  If  the  latter  process  is 
centralized  it  will  be  critically  important  that  the  URS  be 
completed  in  a  manner  that  permits  the  combat  developer  to 
control  the  formulation  of  the  unit  —  to  insert  their  design 
intelligence  —  because  a  different  agency  will  do  the 
documentation . 

Solution 


Our  approach  to  addressing  this  need  was  to  develop  a  user- 
oriented,  computer-assisted  methodology  that  would  address  three 
basic  components  of  the  current  URS  development  process.  These 
components  became  subsystems  of  the  overall  methodology.  They 
address,  respectively: 

(1)  The  need  to  insure  that  the  unit  design  process  is 
driven  by  the  unit  mission; 

(2)  The  actual  design  of  a  structured  unit  up  through 
company  level,  with  its  required  assets;  and, 

(3)  The  need  to  verify  that  the  designed  unit  does  have  the 
capabilities  required. 


Procedures 


We  have  been  fortunate  in  acquiring  the  guidance  and 
direction  of  an  excellent  proponent.  Working  with  and  through 
the  force  design  community  at  CACDA,  we  have  interfaced  with 
force  designers  at  all  TRADOC  schools  and  integrating  centers, 
and  have  benefited  from  their  reactions  to  our  developing 
methodology.  Finally,  we  were  able  to  maintain  a  close  and 
mutually  productive  relationship  with  the  Organization 
Directorate  at  HQ  TRADOC  to  insure  a  fit  between  the  SORD 
methodology  and  those  processes  that  build  on  a  URS  to  document  a 
TOE  unit. 

It  was  necessary  to  undertake  an  ambitious  research  task  to 
develop  a  useful  computer-based  methodology.  After  developing  a 
macro-model  of  the  URS  development  process,  we  developed  and 
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verified  design  specifications,  and  created  and  demonstrated 
rapid  prototypes  of  computer  screens.  As  the  various  utility  and 
other  functions  were  coded,  we  demonstrated,  verified,  and 
refined  successive  prototypes  of  the  methodology  on  the  basis  of 
feedback  received  from  the  proponent  and  user  community.  A  pilot 
test  of  the  complete  methodology  was  conducted  at  Ft.  Leavenworth 
under  the  sponsorship  of  the  Current  Forces  Directorate. 

After  making  refinements  to  the  software  and  user's  manual 
based  on  the  results  obtained  during  the  pilot  test,  the  SORD 
methodology  was  field  tested  in  January,  1989.  There  were  six 
players  in  the  field  test  whose  experience  with  personal 
computers  and  with  the  unit  design  and  documentation  processes 
ranged  from  zero  to  over  10  years.  Each  player  used  SORD  to 
design  two  units  from  scratch.  Collectively,  a  total  of  six 
different  types  of  units  were  designed  ranging  in  complexity  from 
a  headquarters  and  headquarters  company  of  an  armored  brigade 
through  an  air  defense  artillery  weapon  firing  battery  to  a 
personnel  service  company.  After  some  fine-tuning  based  on 
results  from  the  field  test,  the  SORD  methodology  and  a  user- 
verified  user's  manual  were  handed  over  to  the  government  in 
February  1989. 

Since  then,  TRADOC  has  funded  development  of  SORD  Version 
1.5,  which  was  fielded  to  selected  TRADOC  facilities  in  January 
1990.  Presently,  TRADOC  has  allocated  funds  for  SORD  Version  2.0 
which  will  incorporate  some  additional  fine-tuning  of  the 
software  and  will  also  address  changes  in  the  methodology  driven 
by  feedback  from  the  user  community.  SORD  Version  2.0  is 
scheduled  for  fielding  throughout  the  Army  in  January  1991. 


THE  SORD  PROCESS 


Computer  Hardware  Requirements 

The  equipment  required  to  operate  SORD  is  an  IMB-PC,  IBM-XT, 
or  compatible  personal  computer.  The  computer  must  have  a  hard 
disk  drive  with  at  least  5  megabytes  of  memory,  640  kilobytes  of 
system  memory  with  560  kilobytes  free,  and  a  graphics  board  with 
a  resolution  equal  to  or  compatible  with  a  color  graphics 
adapter.  The  printer  must  have  graphics  capability;  a  graphics 
capable  dot-matrix  printer  will  be  adequate  if  it  is  accompanied 
by  a  program  which  will  convert  screen  graphics  into  a  graphics 
form  for  the  printer. 

Assumptions  and  Conditions 

The  point  that  must  be  stressed  here  and  elsewhere  is  that 
while  SORD  will  create  a  standard  structure  in  which  a  combat 
developer  will  design  an  Army  unit,  SORD  cannot  be  used  as  a 
substitute  for  the  thought  processes  of  an  experienced  unit 
designer  or,  at  least,  an  experienced  combat  developer.  The 
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following  conditions  both  drove  and  constrained  the  development 
of  the  SORD  methodology. 

(1)  The  user  of  SORD  is  an  03/04  branch-qualified 
commissioned  officer  or  a  civilian  with  comparable  military 
knowledge  and  experience.  SORD  further  assumes  that  the  user  has 
access  to  and  is  aware  of  sources  of  information  that  are 
required  to  develop  a  URS.  In  short,  SORD  assumes  an  expert 
user. 


(2)  SORD  assists  the  expert  user  in  moving  in  one  standard 
and  manageable  step  at  a  time,  from  the  receipt  of  a  unit's 
mission  through  to  the  printout  of  a  completed  URS  report. 

During  the  process,  SORD  gives  appropriate  structured  guidance 
through  the  use  of  probe  questions,  keywords,  examples,  and  other 
prompts.  Throughout  the  process,  SORD  provides  a  pre-formatted 
working  file  in  which  the  user  will  record  inputs  to  the 
development  of  the  URS.  When  the  URS  is  completed,  the  user  will 
also  have  recorded  a  complete  audit  trail  so  that  others  will  be 
able  to  reconstruct  each  step  of  the  development  process. 


(3)  SORD  is  generally  a  serial  process,  but  one  that 
maintains  specified  elements  of  flexibility.  The  user  may  skip 
some  steps  in  the  process  and  come  back  to  them  after  finishing 
other  steps.  The  user  also  is  allowed  the  flexibility  to  review 
at  any  time  steps  already  completed  in  the  process.  Most 
importantly,  SORD  is  transportable;  different  components  of  the 
SORD  process  may  be  performed,  sequentially  or  simultaneously,  by 
several  geographically  dispersed  individuals. 


(4)  SORD  is  fast.  A  guiding  rule  in  the  development  of  the 
SORD  methodology  was  that  it  is  better  to  have  an  80  percent 
solution  in  hours  than  a  95  percent  solution  in  weeks.  The  speed 
at  which  SORD  will  permit  the  development  of  a  URS  is,  of  course, 
a  function  of  the  extent  to  which  the  user  has  relevant 
experience  and  access  to  pertinent  information.  The  objective  is 
that  an  experienced  user  working  full  time  should  be  able  to 
produce  5  or  6  versions  of  a  particular  unit  in  3  to  5  days. 


The  Process 


The  flow  diagram  in  Figure  1  shows  the  three  major 
components  of  SORD,  the  Mission  to  Function  System  (MFS) ,  the 
Unit  Design  System  (UDS) ,  and  the  Design  Evaluation  System  (DES) . 
As  can  be  seen  in  Figure  1,  SORD  also  incorporates  a  Crew/Cell 
Database,  and  a  report  producing  module.  Each  of  these 
components  of  the  SORD  methodology  will  be  described  in 
succeeding  sections. 
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MISSION  FUNCTION  SYSTEM  (MFS)  UNIT  DESIGN  SYSTEM  (UDS) 


Figure  1.  A  flow  diagram  showing  the  components  of  the  SORD 
methodology  and  the  possible  transition  among  these  components. 


Mission  to  Function  System  (MFS^ 

The  mission  to  function  system  is  designed  to  ensure  that 
the  unit's  design  is  driven  by  its  mission.  This  requirement  is 
one  of  the  weaker  steps  in  the  current  URS  development  process. 
Presently,  mission  analysis  is  often  derived  in  an  unstructured, 
subjective  manner  from  information  contained  in  concept  papers 
and  doctrinal  literature.  Furthermore,  the  results  of  a  mission 
analysis  are  rarely  as  quantitative  as  they  should  be.  This  step 
in  the  design  of  units  (in  which  mission  requirements  should  be 
designated  and  translated  into  quantified  statements  of  required 
functions  and  subfunctions)  is  probably  the  largest  source  of 
variation  in  URSs  produced  by  different  combat  developers.  The 
MFS  contains  three  modules. 
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The  first  module  in  this  system,  called  Mission 
Conditioning,  is  designed  to  insure  that  the  mission  to  be 
accomplished  contains  all  its  required  components  or  tasks  and 
that  the  user  fully  understands  the  unit  mission  and  its  related 
context.  The  system  prompts  the  user  to  create  an  organized 
database,  worksheet,  or  schematic  that  will  be  used  to  define  the 
unit's  required  capabilities.  Specifically,  the  system  offers 
suggestions  on  the  type  of  information  that  is  important  and 
where  to  locate  it.  This  information  includes  the  concept  of 
operations,  area  of  operations,  and  threat  specifications,  much 
of  which  may  be  included  in  a  standard  scenario.  A  record  is 
created  to  document  the  precise  source  of  this  information,  to 
include  personal,  unpublished  sources  (e.g.,  a  local  "expert"). 
Upon  completion  of  this  module,  the  user  has  a  clear,  documented 
expression  of  the  unit  mission,  the  mission  conditions,  the 
assumptions  made,  and  a  prioritized  task  list. 

The  second  module,  called  Mission  Quantification,  prompts 
the  user  to  provide  short  answers  to  a  series  of  questions  keyed 
to  each  task  of  the  mission.  The  user  will  have  to  "look  up", 
calculate,  or  otherwise  formulate  the  answers  to  these  questions 
in  the  process  of  quantifying  or  specifying  the  key  attributes  of 
the  mission.  The  questions  address  unit  capabilities  such  as: 
"How  much?,  how  far?,  how  fast?,  how  long?,  and  how  accurately?" 
The  user  may  ask,  then  answer  a  question  not  given  by  the  system 
to  further  quantify  an  important  attribute  of  the  mission. 

In  this  and  other  components  of  SORD,  the  user  may  freely 
move  among  modules  and  steps  within  a  module  until  required  data 
(i.e.,  inputs)  become  available.  The  user  may  also  default  a 
question  or  probe;  some  broad  attributes  may  defy  quantification 
or  specification  or  simply  not  be  .pplicable  for  a  given  mission 
or  task.  Upon  completion  of  this  module,  the  user  has  a  collated 
list  of  the  composite  requirements  for  each  task  of  the  mission. 

The  third  and  last  module  in  MFS,  Function  Determination, 
assists  the  user  in  partitioning  each  mission  task  into  the 
functions  and  subfunctions  required  for  accomplishment  of  the 
task.  For  the  purposes  of  the  URS,  it  is  sufficient  to  partition 
each  task  into  up  to  19  functions,  where  the  functions  are 
defined  by  seven  action  verbs  and  some  direct  objects  of  the 
verbs.  These  generic  functions  are  all  inclusive  and  capable  of 
capturing  the  actions  required  of  any  type  of  unit.  Then,  by 
working  through  a  different  but  similarly  structured  and  menu- 
driven  worksheet  for  each  of  the  applicable  functions,  the  user 
will  further  specify  and  describe  the  functions  that  must  be 
accomplished  if  the  mission  is  to  be  successfully  accomplished. 
For  example,  if  a  function  of  the  unit  is  "to  move  cargo,"  the 
user  could  specify  function  attributes  such  as  what  types  of 
cargo  (bulk,  fuel,  or  water),  how  it  is  to  be  transported  (foot, 
ground,  air,  or  water) ,  and  over  what  distance  (less  than  3  km, 

4  -  10  km,  or  more  than  10  km) . 

After  completing  the  three  modules  contained  in  the  MFS,  the 
user  has  documented  the  results  of  a  mission  analysis  that 
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specifies,  down  to  the  function  level,  the  precise  requirements 
that  must  be  fulfilled  by  the  unit.  Given  this  information,  and 
the  experiences  acquired  in  the  process  of  documenting  it,  the 
user  is  ready  to  actually  design  the  unit. 


Unit  Design  System  fUDS^ 

The  unit  design  system  will  aid  the  user  in  designing  a 
structured  unit  comprised  of  the  appropriate  numbers  and  types  of 
major  materiel  and  personnel  assets  required  to  accomplish  the 
mission.  Basically  this  is  done  by  matching  functional 
requirements  of  the  mission  with  the  capabilities  of  key  materiel 
and  personnel,  and  then  sizing  out  the  unit  and  organizing  it 
into  a  structured  entity. 

The  UDS  consists  of  five  modules.  The  first  two  modules. 
Materiel  Identification  and  Personnel  Identification,  operate  in 
a  similar  manner  to  assist  the  user  in  identifying  candidate 
materiel  systems  and  soldier  specialties  to  be  used  in  the  unit 
to  perform  the  functions  previously  specified.  Currently,  the 
user  must  have  access  to  and  manually  input  to  SORD  information 
on  potential  materiel  and  personnel  assets.  For  example,  each 
member  of  a  particular  class  of  tanker  trucks  can  transport  2500 
gallons  of  fuel  and  a  trailer  mounted  storage  tank  can  hold  600 
gallons.  Or,  two  military  occupational  specialties  (MOS  76Y  and 
77F)  have  the  capability  to  satisfy  a  mission  requirement  for 
receiving,  storing  and  processing  fuel. 

Once  candidate  materiel  systems  and  personnel  have  been 
identified,  their  relative  capabilities  must  be  matched  against 
the  mission  requirements.  In  the  Unit  Sizing  Module,  SORD  will 
assist  the  user  in  assigning  the  necessary  numbers  and  types  of 
candidate  materiel  systems  and  personnel  to  the  unit.  SORD 
reminds  the  user  of  any  unassigned  candidates  and  makes  available 
any  of  the  information  previously  input  into  the  working  file. 

For  example,  the  user  may  designate  that  a  specific  number  of 
2500  gallon  tanker  trucks  are  required  to  move  a  required  volume 
of  fuel  under  conditions  specified  in  the  mission  scenario;  SORD 
would  remind  the  user  that  600  gallon  fuel  tanks  carried  on 
trailers  also  had  been  identified  as  satisfying  the  requirement 
to  transport  fuel. 

The  Command  and  Control  (C2)  and  Structure  Module  assists 
the  user  in  creating  an  organizational  structure  for  the  unit, 
and  in  assigning  additional  personnel  and  materiel  to  satisfy 
requirements  imposed  by  command,  control,  and  other  support 
functions.  There  are  two  submodules.  The  Structure  submodule 
prompts  the  user  to  review  relevant  doctrine,  concepts  of 
operations  and  other  documentation  to  identify  any  guidance  that 
may  suggest  how  personnel  and  materiel  assets  could  be  organized. 
For  example,  organization  guidance  generally  recommends  symmetry 
in  structuring  a  unit;  like  elements  have  the  same  number  and 
types  of  assets.  Then,  working  from  the  lowest  level 
organizational  elements,  the  user  names  an  element  and  assigns 
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assets  to  it.  The  process  is  repeated  until  all  lowest  level 
elements  have  been  named  and  all  assets  have  been  assigned.  SORD 
will  keep  track  of  and  display  assets  not  yet  assigned.  Once  all 
the  lowest  order  elements  have  been  defined,  the  user  is  guided 
into  naming  the  next  higher-order  elements  and  assigning  to  them 
lower  level  elements. 

The  C2  Submodule  starts  with  the  assignment  of  C2  personnel 
to  the  lowest  level  elements  of  the  unit  and  moves  up  through 
higher  level  elements.  SORD  presents  to  the  user  the  grade 
structures  recommended  for  each  element  (based  on  guidance  in  the 
AR  611  series) .  For  example,  a  typical  infantry  platoon  is 
authorized  a  platoon  sergeant  and  an  infantry  company,  a  first 
sergeant.  Finally,  the  user  will  be  encouraged  to  determine  if 
any  of  the  C2  or  support  assets  added  to  the  unit  call  for  the 
assignment  of  additional  assets  (e.g.,  a  vehicle  for  the  first 
sergeant) . 

The  last  module  in  the  unit  design  system,  called 
Constraints  Application,  permits  the  user  to  determine  if  the 
unit,  as  tentatively  designed,  hac  exceeded  any  materiel  or 
personnel  constraints  that  had  been  imposed.  If  so,  the  user  is 
directed  to  AR  310-31  for  guidance  in  TOE  reduction.  SORD  also 
will  display  tasks  that  were  previously  rated  as  having  the 
lowest  priority  for  the  unit.  After  reviewing  these  materials, 
the  user  will  select  specific  assets  to  be  eliminated  from  the 
unit  design.  At  this  point,  a  unit  will  have  been  designed  that 
possesses  the  assets  required  to  accomplish  its  assigned  mission. 


Design  Evaluation  System  (DES^ 

The  last  major  component  of  SORD,  the  design  evaluation 
system,  will  aid  the  user  in  assessing  and  verifying  that  the 
capabilities  of  the  unit  designed  in  the  UDS  will  match  the 
mission  requirements  that  were  determined  in  the  MFS .  The  DES 
also  will  maintain  a  file  of  all  unit  designs  (including 
alternative  designs  for  a  specific  set  of  mission  requirements) 
and  provide  a  format  for  report  generation. 

Two  key  terms  to  note  here  are  verify  (as  opposed  to 
validate)  and  capability  (as  opposed  to  effectiveness) .  At  this 
stage  in  the  CBRS  it  is  necessary  only  to  confirm  that  the 
mission  requirements,  derived  in  the  top-down  MFS  process,  are 
matched  by  the  capabilities  of  the  designed  unit,  derived  in  the 
bottom-up  UDS  process.  Also,  at  this  stage  in  the  CBRS,  it  is 
necessary  only  to  address  the  aggregated  capabilities  of  the 
materiel  and  personnel  assets  that  were  organized  into  the 
designed  unit.  It  would  be  premature  at  this  point,  and  not  cost 
effective,  to  attempt  to  validate  the  actual  operational 
effectiveness  of  the  designed  unit.  These  steps  are  more 
properly  assigned  to  wargaming  exercises. 

SORD  will  assist  the  user  in  comparing  the  capabilities  of 
the  designed  unit  and  the  requirements  for  each  function  within 
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each  task  of  the  unit  mission.  The  unit's  capabilities  and  the 
mission  requirements  are  presented  side-by-side  on  the  computer 
screen  to  facilitate  these  comparisons. 

After  examining  the  capabilities  and  requirements  for  each 
function,  the  user  must  accept  or  reject  that  aspect  of  the 
proposed  design.  As  an  intermediate  action,  the  user  may  wait, 
but  flag  that  particular  feature  of  the  unit  design  for 
additional  scrutiny  by  indicating  that  there  is  either  an  over  or 
under  capacity  designed  into  the  unit  for  a  particular  function. 
Some  mismatches  between  requirements  and  capabilities  may  lead 
the  user  to  consider  redesigning  the  unit,  or  reassigning  a 
function  to  a  higher,  supporting,  or  supported  element.  The 
rationale  necessary  to  support  or  clarify  any  decision  can  be 
recorded  in  a  memo  field  for  later  reference. 

Once  the  user  has  completed  reviewing  and  acting  on  all  the 
comparisons  of  capabilities  and  requirements,  he  or  she  can  store 
the  entire  working  file  for  that  design  exercise  into  a  history 
file  for  later  reference,  or  instruct  SORD  to  prepare  and  print  a 
report  based  on  information  contained  in  the  history  file.  All 
the  information  used  in  developing  the  unit  design,  including 
sources  of  data  and  rationale  for  decisions  are  available  in  the 
file  for  later  examination. 


Crew/Cell  Database 

The  Crew/Cell  Database  is  a  component  of  SORD  that  can  be 
used  to  develop  crews  or  cells  of  personnel  and  materiel  assets. 
The  idea  behind  this  database  is  that  there  will  be  specific 
clusters  of  assets  that  will  be  used  repeatedly  in  designing 
different  elements  within  a  unit  and  also  across  different  units. 
The  crew/cell  database  will  permit  the  user  to  develop  such  a 
cluster  of  assets  and  then  store  that  information.  Once  stored 
in  the  database,  the  assets  that  define  a  crew  or  cell  can  be 
called  up  and  used  at  several  points  in  the  UDS. 

SORD  treats  a  crew  and  a  cell  differently.  A  crew  is 
defined  by  SORD  to  be  a  group  of  personnel  that  are  employed  in 
conjunction  with  a  particular  materiel  system  (e.g.,  a  M109  155- 
mm  self-propelled  howitzer) ;  if  that  system  is  assigned  to  a  unit 
while  the  user  is  in  the  UDS,  SORD  can  automatically  call  up  and 
include  the  crew  of  the  system  into  the  personnel  assets  file  for 
the  unit.  On  the  other  hand,  SORD  defines  a  cell  as  a  cluster  of 
personnel  that  perform  a  function  within  a  unit  but  are  not 
linked  to  a  particular  materiel  system  (e.g.,  an  SI  section  of  a 
headquarters  and  headquarters  company) .  When  operating  within 
the  UDS  of  SORD,  the  system  will  prompt  the  user  to  include  as 
appropriate  any  cells  that  had  previously  been  developed  and 
stored  in  the  database. 
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Report  Generator 


At  present,  SORD  has  the  capability  to  generate  a  single, 
standard  formatted  URS  report  only.  This  feature  of  SORD  can  be 
upgraded  to  permit  the  production  of  a  variety  of  customized 
reports.  Exercising  this  option  in  the  main  DES  menu  will  call 
up  a  computer  screen  that  prompts  the  user  to  provide  information 
for  the  report  title  page,  such  as  the  title,  proponent,  author, 
editor,  reviewer,  and  date  of  creation.  Once  this  information  is 
provided,  SORD  will  complete  and  generate  the  entire  URS  report. 
The  report  can  be  produced  either  on  the  screen  or  on  paper. 


CONCLUSIONS 


Summary 

The  SORD  methodology  is  a  user-oriented,  computer-assisted 
tool  that  addresses  three  basic  components  of  the  unit  design 
process:  (a)  insuring  that  the  unit  design  process  is  driven  by 

the  unit's  mission;  (b)  designing  a  structured  unit  with  all  its 
required  materiel  and  personnel  assets;  and  (c)  verifying  that 
the  designed  unit  does  have  the  capabilities  required  to 
accomplish  its  mission. 

SORD  assists  the  unit  designer  in  preparing  a  standardized 
unit  reference  sheet.  SORD  does  not  replace  the  experienced  unit 
designer;  it  is  not  an  expert  system  that  employs  artificial 
intelligence.  SORD  does  not  alter  the  unit  design  process;  it 
makes  that  process  more  efficient  and  reliable. 


Benefits 


(1)  SORD  will  permit  the  rapid  development  of  alternative 
conceptual  designs  and  the  efficient  transfer  of  those  designs  to 
others  in  the  combat  development  process  and  to  those  who  are 
responsible  for  the  prescribed  and  increasingly  automated  process 
of  preparing  organizational  documentation. 

(2)  Because  of  the  thoroughness  of  the  designs  it  helps  to 
create,  SORD  will,  in  most  instances,  eliminate  the  need  to 
develop  an  Automated  Unit  Reference  Sheet  in  the  process  of 
developing  draft  TOEs. 

(3)  SORD  will  permit  the  centralization  of  TOE 
documentation  within  the  Army.  Such  a  realignment  will  result 
in  substantial  personnel  and  monetary  savings. 
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